OK, well now that's enough detail to likely resolve things. Note what it says: IIS Cannot read the configuration file (C:\WebSites\restapi\web.config) due to insufficient permissions.
First, you may say "there is no such file in that folder"....but IIS can't even see into it to know. As you may know, when you create a site you name its webroot, and then IIS always tries to look in that webroot for a web.config (which has site-level config details, which can be set either in the IIS UI to be saved in that file, and vice-versa).
So to whom should such be "permissions" granted? The user running the site's application pool (the pool's "identity"). You can see what app pool a site uses by right-clicking the site and choosing "manage web site>advanced properties". The app pool is the first value shown. Then go to the application pools list (top left of IIS display), which will show all app pools and a column for their identity. (Since IIS 7.5, new sites get their own app pool by default, but one can change that when creating or editing a site.)
All that said, the DEFAULT identity for a new app pool (since IIS 7) is simply "applicationpoolidentity". So we could argue THAT is the user who needs permissions to read that file. But it's both a bit more complicated and also has a simple workaround you could consider.
First, how would you change a folder's permissions to name the user? Some may know you can go into Windows File explorer to view that webroot folder (in your case, C:\WebSites\restapi), and right-click it, then choose properties, then the "security" tab, which will show WHO currently has permission.
To modify it, click "edit" then "add"...but if you just type "applicationpoolidentity" as the user, that won't work. Formally, it's a hidden user: you won't even see it if you use the "advanced" button there and its "find" option. The formal name is: iis apppool\pool name (and yes, spaces are allowed, and case does not matter--but use \ not /). So if the site was "test site" and the app pool (created by default) was "test site", and its identity showed (by default) to be "applicationpoolidentity", the actual user would be: iis apppool\test site
(BTW, when entering ANY username while adding/editing that security tab, note that there's a "locations" option...and it might default to something other than this machine itself. You need to change that to this machine itself to work with such accounts that are on the machine. Click the "locations" button there, and normally the first value shown is the local machine itself.)
You need to give it only read permissions by default. Do that, and test the site now (no restart of anything needed).
And what if you don't want to bother with identifying the identity? If you google this problem you may even see someone proposing that the user to give permissions to is "IIS_IUSRS". Technically, that's a windows "group" that contains ALL the app pool identies for ALL sites. (Again, that's defined only for the machine itself, so be sure the "location" points to that when trying to add it.) And sure, you could just use that if you aren't concerned about limiting access for only the ONE identity of the app pool for the site. (Doing this also lifts the burden of dealing with if you or anyone ever CHANGES the identity for the pool, or changes what pool the site uses--which would now have a different identity.)
Finally, there are some situations where you may find you need to need to add as well one more user (with permission to that site root folder), another special local Windows user related to IIS is: IUSR. I've never fully explored when one might be needed over/in addition to the other. But consider that as an option.
I know that's all a lot to take in. In the interest of time, I am not taking screenshots--but you can find those in other resources on the web, as this is a VERY common IIS problem with these common solutions. Again, it's a matter of seconds of effort to change these things for one who knows what they're doing and who connects the dots from that error to the solution. And I didn't even want to guess originally that this might be your problem (It could have instead been a CF error, which is why I had you check the CF logs.)
Let us know if that gets you going. If not, we can see how ot goes here or again solve it far more quickly together in a shared desktop consulting session.
... View more